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BACKGROUND OF THE INVENTION 
5 The invention relates to the field of the remote control of actuators and in 

particular, the wireless control of actuators used in the amenities and security of 
buildings, in particular for lighting, operating closures, solar protection, ventilation 
and air-conditioning systems etc. 

In the current design of such systems, such actuators and/or associated sensors 

10 are controlled by control units or control points capable of communicating by 
reception but also by transmission via a bidirectional link, typically a radio frequency 
link. The actuators and or sensors and the control units can therefore be qualified 
genetically as bidirectional objects. The actuators and or sensors are often installed in 
the parts of the building which are difficult to access for the installer and even more 

1 5 difficult for the user. 

The control points are unidirectional or bidirectional, roving or fixed. Very 
often a fixed control point is itself battery powered, which avoids wiring. When a 
control point is equipped with a transceiver, the reception function can only be 
activated on command or intermittently in order to limit consumption. 

20 A pairing procedure makes it possible to associate a common identifier with a 

pair formed of an actuator and a control point. The sharing of a common identifier 
then makes it possible for the actuator to recognize the controls originating from the 
control point, in command to respond to it. The pairing procedure can be repeated so 
as to control several actuators from one control point or also so that one actuator 

25 responds to several control points. Depending on the pairing procedure, the identifier 
is transmitted from the control unit of the actuator to the control point, which records 
it, or conversely from the control point to the control unit of the actuator, which 
records it. Pairing solutions are, for example, described in US-A-4 529 980 or US-A- 
5 148 159 or also in French patent applications filed by the Applicant under serial 

30 numbers 01 09369 of July 13, 2001 and 01 16709 of December 21, 2001. 

When it is a question not only of amenity but also security, a problem arises if 
a control point is lost or stolen. In fact, a stolen actuator can be used remotely, for 
example, to deactivate an alarm or also to open a door or a rolling shutter. 
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US patent Re 36,703 presents a solution to such a problem. It relates to a 
control unit of an actuator for garage doors which is able to learn several identifiers, 
all different, belonging to different remote control transmitters. A software or 
mechanical pointer allows a new memory location to be assigned to a new transmitter. 
5 In the case of loss (or stealing) of one of the transmitters, the corresponding memory 
location is pointed to in order to enter the code of the replacement transmitter there. 
The old transmitter thus becomes invalid in that its identifier is overwritten by the 
writing of a new identifier. This solution requires that a table of the relationships 
between transmitters and memory locations assigned to each transmitter be kept in a 
10 safe place. 

EP-A-0,688,929 describes learning mechanisms in code hopping systems, 
with an analog solution. This document states that it may be necessary to exclude a 
transmitter from the system. The solution proposed is as follows: an encoder is 
excluded by suppressing the corresponding codes in the decoder - in other words 

15 simply separating the encoder and the decoder. 

Another solution consists in starting a pairing procedure of all of the actuators 
again. The French patent application filed on 13.07.01 under serial number 01 09369 
thus proposes actuators, in which action on the power supply causes actuation of the 
programming mode. Another solution consists in resetting an actuator by actuating the 

20 phase of a specific wire as disclosed in FR-A-2,808,834. It is understood that such 
means requires that the pairing procedures be started again completely. To 
compensate for the loss or disappearance of a command point we are thus required to 
delete the indentifiers of all of the command points of the installation. Moreover this 
solution is complex and it is not always possible to implement it, in particular in the 

25 case of command points preassigned to actuators in the factory or when the various 
actuators are not accessible. 

In the field of electronic locks it has been proposed to take advantage of the 
introduction of a new key to eject the code of the preceding one. Such a method is 
used for example in the documents EP-A-0, 17 1,323 or even earlier US-A-3,82 1,704. 

30 In a hotel room lock, an electronic key contains a code with two fields A and B. Field 
A contains the valid access code, field B contains the authorization field. A new key is 
provided for the next client, this time containing B and C. The first field is used to 
control the opening if there is identity between the one read on the key and the one 
recorded in the lock. If there is no identity, the lock compares this first field to the 
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authorization code recorded in the lock. If there is identity, the lock records this code 
as a valid access code and records the second field of the key as a new authorization 
code. 

EP- A- 1,085,481 discloses an installation in which all of the elements of the 
5 installation share a site code, unique to the site. The site code is used by the 
transmitters to encrypt the information transmitted to the receiver. The receiver 
decrypts the information that it receives from the transmitters, using the site code. It 
responds to the commands of a transmitter if the information that it receives from this 
transmitter agrees with the information received previously from the transmitter. The 
10 advantage presented in the document is that any programming of the receiver is 
avoided. However, this document does not mention the problem of loss of a 
transmitter or deletion of a transmitter; in fact the proposed solution makes the 
deprogramming of one of the transmitters impossible. 

Thus a problem still exists in the case of loss or stealing of a control unit, or 
15 more generally when seeking to exclude an object from a group of paired objects. 
SUMMARY OF THE INVENTION 

The invention thus discloses a method for reprogramming bidirectional objects 
containing a common key, at least two objects being paired to allow the sending of a 
command from one object of the pair to the other object of the pair and the execution 
20 of the command by the other object; the method comprises the steps of: 

- providing the objects with a new common key; then 

- when a command is sent from one object to another object with which it is 
paired, verification that the two objects contain the new common key, and 

- refusal by the other object to execute the command if the two objects do not 
25 contain the new common key. 

Advantageously, the step of verification for two given objects is implemented 
only when the first command is given following provision of the new common key. 
The step of provision of a new common key can comprise: 

- the generation of a new common key and 

30 - the transmission of the new common key generated. 

In this case the step of generation can be carried out using a single object or 
using two objects. The transmission can be a point-to-multipoint transmission or a 
point-to-point transmission. In this last case, the point-to-point transmission 
preferably comprises an action by the user on each point. 
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It can also be foreseen that the transmission step comprises: 

- a point-to-point transmission in a sub-group of the objects; 

- a point-to-multipoint transmission to another sub-group of the objects. 

In one embodiment, the transmission step comprises, when the new common 
5 key is transmitted from one object to another object, verification that the two objects 
contain the old common key. 

The invention also discloses an operating program for a bidirectional object 
capable of storing at least one common key and at least one piece of information on 
pairing, comprising: 
10 (a) a routine of reception of a new common key; 

(b) a routine of reception of a command; 

(c) a routine of verification for a command received from a paired transmitter 
object of the presence of the common key in the transmitter object, and 

(d) a routine of refusal to execute the command if the verification is negative. 
15 Advantageously the routine of verification is used for a given pairing only 

when the first command is received. 

The invention also discloses an operating program for a bidirectional object 
capable of storing at least one common key and at least one piece of information 
about pairing, comprising: 
20 (a) a routine of reception of a new common key; 

(b) a routine of transmission of a command to a targeted paired object; 

(c) a routine of verification of the presence of the common key in the targeted 
object. 

Advantageously, the routine of verification for a given pairing is implemented 
25 only when the first command is transmitted. 

One or the other of these programs can also comprise a routine of 
generation of a new common key. This preferably has a sub-routine of transmission of 
a command to generate the common key to another object. 

A routine of transmission to another object of a new common key 
30 or a routine of transmission to several other objects of a new common key can also be 
foreseen. 

Finally, the invention discloses a bidirectional object having: 

- a stage of reception; 

- a stage of transmission 
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- a logical unit controlling the step of reception and the step of transmission, 
and 

- a memory containing such a program. 

Other characteristics and advantages of the invention will become apparent 
5 when reading the description which follows, given by way of example and with 
reference to the drawings 
BRIEF DESCRIPTION OF THE DRAWINGS 

- FIG. 1, a schematic view of an installation allowing the implementation of 
the invention; 

10 - FIG. 2, a flowchart of a method according to the invention; 

- FIG. 3, a flowchart of another embodiment of a method according to the 
invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

In the remainder of the description, the invention is described in an example of 

15 application with pairing of integrated home automation systems; it is not limited to 
such systems. Hereafter the words " command transmitter" and "command receiver" 
are used to designate objects whose function is to transmit or receive the commands 
given by a user; a command transmitter is also commonly called control unit, while a 
command receiver is an actuator or an associated sensor. These names are not 

20 representative of the functionalities of the "transmitters" or "receivers", which from 
the point of view of the signals are capable of transmitting as well as receiving. Thus 
we could have said "bidirectional object", i.e. an object presenting transmission and 
reception capabilities. For clarification of the explanation the words "transmitters" or 
"receivers" are used - which represent only the assignment of a given bidirectional 

25 object to a particular usage. 

In the remainder of the description it is also assumed that each bidirectional 
object is equipped with a univalent identifier; this can be an identifier corresponding 
to a code of the object, given in the factory and which can not be modified; this can 
also be a number which can be modified, such as a random number chosen in the 

30 object or a number chosen using microswitches. The origin of the identifier has no 
effect on the functioning of the method. It is also noted that the identifier used 
hereafter can be modified after definition of the group or after pairing: it serves only 
to identify an object during the pairing. 

FIG. 1 shows a schematic view of an installation in which the method can be 



implemented. The installation comprises an operating unit 2. This operating unit can, 
for example, roll blinds up or down, open or close rolling shutters or a garage door, 
switch a light on or off, open a door, trigger or clear an alarm, etc. The operating unit 
is connected to a receiver. The command receiver has an antenna 6 which allows it to 
5 receive commands transmitted via a radio link from a command transmitter; the 
command receiver 4 can also transmit signals, for example via radio link, using the 
same antenna 6. The radio transmission of commands from a transmitter to a receiver 
or vice versa is known per se and is not described here in more detail. 

FIG. 1 also shows a plurality of operating units 8, 12, each with their 

10 command receiver 10, 14. It also shows command transmitters 16, 18 and 20; these 
are suited to transmitting by radio link one or more commands addressed to the 
receivers 4, 10, 14 and have an antenna for this purpose (not shown). Typically, a 
command transmitter, in the case of controlling a rolling shutter, can transmit 
commands to raise or lower the shutter, or to stop the shutter; other commands can 

15 also be given, such as placing the shutter in pre-programmed positions, commands for 
programming the shutter, etc. The command transmitter thus has one or more devices 
allowing the user to enter a command, in the simplest case one or more control 
buttons. A command transmitter is also capable of receiving signals from the 
command receiver(s); as with the command receiver, the same antenna is used. 

20 A number of transmit or receive transmission channels can be provided for the 

command transmitter and the command receiver; in a simple configuration, radio is 
used, and thus the transmitter as a sender is a "transceiver", i.e. a transceiver. 

Some of the bidirectional objects - transmitters and command receivers - are 
paired. The pairing, described in the documents from the state of the art mentioned 

25 above, consists in making each object of a pair "learn" the identifier of the other 
object of the pair; after pairing, one object of a pair executes the commands which are 
transmitted to it by the other object of the pair. These commands can be of very 
different nature depending on the installation; in a rolling shutters installation the 
commands are typically commands to raise or lower the shutters; commands for 

30 programming for the creation of other pairings can also be foreseen. In an alarm 
installation, the command can be to set off or to stop the alarm or a programming of 
functions. Thus "command" can thus generally describe an instruction transmitted by 
one object to another object. 
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In an installation there can be as many pairings as pairs of objects and the 
reprogramming method described here applies independently of the way in which the 
pairing is realized. 

In the following we consider, by way of example, the case where the following 
5 pairs are defined: (4,16), (10, 16), (10, 18), (4, 20), (10, 20) and (14, 20); the 
transmitter 16 controls the receivers 4 and 10, the transmitter 18 controls the receiver 
10 and the transmitter 20 controls all of the receivers. 

The physical and logical structure of a bidirectional object which can be used 
in such an installation is known to a person skilled in the art; in particular reference 

10 can be made to the description given with reference to FIG. 2 of the French patent 
application 02 01631 of February 11, 2002. In summary, a bidirectional object 
comprises a reception stage suited to receiving signals from the other objects or from 
some of them, a transmission stage suited to transmitting signals to the other objects 
or to some of them and a logical unit controlling the reception stage and the 

15 transmission stage. The object also has a memory, containing the programs used in the 
logical unit and in particular the operating programs of the object. As explained 
below, the memory of the object can also contain at least one common key; the object 
can also contain pairing information, for example identifiers of other objects stored in 
the memory. According to their use as command transmitter or as command sender, 

20 the objects can have different inputs (buttons, microswitches, switches) or outputs (to 
an operating unit); the operating program can also differ according to the functions for 
which an object is designed. 

The problem resolved by the invention is that of reprogramming bidirectional 
objects, which arises when seeking to exclude an object from a group of paired 

25 objects. This problem arises in particular in the case of loss or stealing of an object. 
This problem also arises when seeking to replace one object with another, for example 
when replacing an old transmitter with a new transmitter. In the example proposed, in 
the case where the object 16 disappears it would be useful to be able to replace this 
object with a new command transmitter, without however having to reprogram the 

30 four other pairings. 

FIG. 2 shows a flowchart of the steps of the method of the invention. Steps 24 
and 26 are steps of providing the objects with a common key and of pairing amongst 
the objects; these steps are not strictly speaking a part of the method and can be 
carried out according to any method desired. Their order can be reversed, the step of 



pairings preceding that of provision of a common key. At the end of these steps a 
common key is provided to all of the objects which are to subsequently participate in 
the reprogramming. In the most simple case these are all of the objects of the 
installation; it can be imagined that the pairings are defined within two distinct sub- 
5 groups and that a common key is assigned to each of the sub-groups. For the 
provision of this common key the method described in the patent application EP 1 085 
481 or in the French patent application 02 01631 of February 11, 2002 can be used in 
particular. Whichever method is used, at the end of the provision step, the 
bidirectional objects which can subsequently participate in the reprogramming each 

10 have a common key. This common key is, for example, a sequence of numbers stored 
in a memory associated with each of the objects. 

Step 28 corresponds to the disappearance of a command transmitter - which is 
only one example of a situation in which it can be sought to reprogram the objects. A 
disappearance of the command transmitter 16 is considered. 

15 At step 30 a new common key is provided for the objects of the installation - 

but not for the object to be excluded. Various solutions for providing this new 
common key are detailed below. At the end of this step, the objects to be 
reprogrammed - with the exception of the object to be excluded - are provided with 
the new common key. As explained below, according to the nature of the 
. 20 authentification procedure, the new common key can be provided to the different 
objects in different forms. 

At step 32, an object attempts to establish a communication with another 
object with which it is paired in order to transmit a command to it. In the example, a 
command transmitter is used to transmit a command to a command receiver. 

25 At step 34, for the pair of objects assigned by the attempt to transmit a 

command, there is verification of whether the two objects are provided with the new 
common key. If this is the case, step 36 is initiated or otherwise step 38. The 
verification can be carried out according to any authentification procedure allowing 
each object to verify that the other is provided with the new key. In particular the 

30 authentification algorithms of the type described in US-A-5 841 866 can be used. 
Knowledge of the new common key can also be demanded only from some of the 
objects: thus, in an installation, it can be assumed that fixed command receivers - 
such as motors of rolling shutters - do not run the risk of being lost or stolen. For this 
reason it may be sufficient, when attempting to send a command from a command 
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transmitter to a command receiver, to verify that the command transmitter is provided 
with the new common key. In practice the verification requires provision of the new 
common key, in one form or another, to the command receiver. 

At step 36, the two objects are seen as being provided with the new common 
5 key - in other words they are not excluded. The command is thus accepted, i.e. 
executed by its target. This is the case, in the example, if the command transmitters 18 
or 20 are used. The user can thus continue to use command transmitters, as before. He 
does not need to reprogram all the pairings. 

At step 38 the objects are shown as not both being provided with the new 
10 common key. The command is refused - the target of the command thus does not 
execute it. In the example, the command transmitter 16, which has not received the 
new common key, cannot control one of the two command receivers 4 or 10 with 
which it was paired. 

This ensures that the excluded object can no longer be used in the installation, 
15 without all the pairings needing to be reprogrammed. 

Steps 34, 36 and 38 are used for the different pairings considered; they can be 
used successively, whenever an object is used. They can also be used almost 
simultaneously: this could be the case if an object attempts to send a command 
simultaneously to a plurality of other objects. In the example proposed above, when 
20 the object 20 is used for the first time after the provision of a new common key, it 
transmits a command to objects 4, 10 and 14; thus the verification of step 34 is carried 
out three times, on each pair of objects. It could thus be imagined that the object 20 
sends a common validation frame, by which the object 20 signals its knowledge of the 
common key. 

25 FIG. 3 shows a flowchart of a more developed embodiment of the invention. 

In the example of FIG. 3, the verification foreseen in FIG. 2 at step 34 of FIG. 2 for a 
given pair of objects is implemented only in the first attempt at sending a command 
from one object to the other. 

In the example of FIG. 3, the pairings are realized by storage in an object of 

30 identifiers of all of the objects with which it is paired. Thus, in the example, the 
command transmitter 16 stores identifiers of the command receivers 4 and 10, while 
the command receiver 10 stores the identifiers of the command transmitters 16, 18, 
and 20. Moreover, a marker is provided for each identifier stored; the marker is binary 
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and its function appears in the description which follows. In "normal" functioning of 
the installation, the marker has a first value - the value zero for example. 

As in FIG. 2, objects provided with a common key and amongst which 
pairings are defined are assumed. At step 42 a command transmitter disappears. A 
5 new common key is provided in step 44. In each object which has received the new 
common key, the marker associated with each identifier changes value; it changes to 
the value 1. This value denotes that the pairing in question is, temporarily, invalid. 

At step 46 an object sends a command to another object. 

At step 48, in the object targeted by the command, there is verification of the 
10 existence of a pairing. If the pairing exists, step 50 is implemented, otherwise step 52 
is implemented. 

At step 52, in the object targeted, the command is refused if the pairing does 
not exist. This is a normal application of the functioning rules of the objects. 

At step 50, in the object which has received the pairing a test of whether the 
15 corresponding marker is valid is carried out -at state "0" in the example. If this is the 
case, step 56 is implemented, otherwise step 54 is implemented. 

At step 56 the command is executed. 

At step 54, in the transmitter object and in the object targeted by the command 
a test of whether the new key is present is carried out. If this is the case, step 62 is 
20 implemented, otherwise step 60 is implemented. 

At step 60, the pairing is suppressed in the two objects. The pairing is thus 
invalid permanently; in the simplest embodiment, the memories of each of the objects 
of the pair storing the identifier of the other object of the pair are erased. This ensures 
that the excluded object can no longer be used in the installation. More complex 
25 solutions can be foreseen, for example notifying the user with a particular signal or 
causing complete deactivation of the objects. The pairing can also not be suppressed 
until after a second attempt, which gives the user the possibility to transmit the new 
common key to the object not provided with it. 

At step 62, the command is executed and the marker of the identifier of the 
30 other object changes to the value "0" in the two objects. The pairing is again "valid" 
or "restored". 

After steps 52, 56, 60 and 62 step there is a return to step 46. 
The flowchart of FIG. 3 is followed through as explained below. The example 
considered above is considered. After the provision of the new common key, the 



11 

objects 4, 10, 14, 18 and 20 have received the new common key and have changed the 
markers of all their paired objects to u 0'\ thus invalidating all the pairings. 

It is assumed that the object 18 sends a command to the object 10. The 
flowchart is followed through according to steps 48, 50, 54. At step 54, the two 
5 objects are provided with the common key and step 62 is implemented: the markers of 
the identifier of object 10 in object 18 and of the identifier of object 18 in object 10 
change to "0". If object 18 sends a new command to object 10, the flowchart is 
followed through according to steps 48, 50, 56. The presence of the marker makes it 
possible to test for the presence of the new common key only once, which simplifies 

10 the exchanges. 

It is assumed that object 16 is used to transmit a command to objects 4 and 10. 
For each pairing the flow chart is followed through according to steps 48, 50, 54. At 
step 54, object 16 does not have the new common key. For this reason, at step 60, the 
pairing is suppressed. Thus, the identifiers of objects 4 and 10 are suppressed in object 

15 16 and the identifier of object 16 is suppressed in objects 4 and 10. This prevents a 
subsequent attempt to use object 16 from being totally - it would lead to the 
flowchart being followed through according to steps 48 and 52. This also allows a 
memory location to be cleared in the objects to allow other pairings. 

The solution of FIG. 3 makes it possible, when there is a second command, to 

20 not verify again the presence of the common key; a subsequent command can thus be 
executed without verification of the existence of a common key. It also makes it 
possible to determine, for a given object, at what point the group of the objects to 
which this given object is connected has been scanned: in fact, when all of the 
markers have changed back to "0", all of the pairings have been "restored". 

25 In another embodiment, it can be provided that the verification is carried out 

only over a predetermined period of time following the provision of a new common 
key; this embodiment ensures greater security by eliminating objects which are not 
used or rarely used. In this case, at the end of the predetermined time period, the 
identifiers of the objects whose marker is still at "1" are eliminated. 

30 Steps 48 to 62 are implemented for the different pairings considered; they can 

be implemented successively, whenever each object is used. They can also be 
implemented almost simultaneously: this could be the case if an object sends a 
command simultaneously to a plurality of other objects. In the example proposed 
above, when object 20 is used for the first time after the provision of a new common 
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key, it transmits a command to objects 4, 8 and 12; thus steps 48, 50, 54 and 62 are 
carried out three times, on each pair of objects. Thus it could be imagined that the 
object 20 sends a common validation frame, by which object 20 signals its knowledge 
of the common key. 

5 Finally it must be noted that in the examples cited, each pairing is realized by 

the storing in an object of identifiers of all of the objects with which it is paired. As is 
described in the state of the art, the pairing can be more simply realized by a partial 
storing: for example that of the identifier of a command transmitter in a command 
receiver, without the identifier of the command receiver being stored in the command 

10 transmitter, or by storing one of the identifiers or addresses of the command receiver 
in a command transmitter, without said command receiver containing the identifier of 
the command transmitter. In each case the command receiver still has the possibility 
of making the pairing invalid, or of suppressing it, as explained above. 

Various solutions allow provision of a common key to a group of objects as 

15 described below. In a first variant, the provision of a new common key is carried out 
using only one of the roving or fixed remote control points. A specific keyboard 
command or combination of keys, allows this remote control to be entered into a 
mode where it generates a new key NK, for example using a semi-random algorithm, 
or by any other means, this has no effect on the contents of the invention. It is noted 

20 that the old common key OK can be kept in the memory by the remote control, for the 
reasons explained below. This variant has the advantage of simplicity and facility of 
implementation. 

In a second preferred variant, at least two control points are required to allow 
changing of the common key of one of them. Thus, if seeking to change the common 
25 key using the remote control Tl, the keyboard procedure of the first variant is used, 
but this causes transmission by Tl of a request for particular authentification. In the 
transmission frame, Tl sends sign proving that it contains the old common key - this 
can be the value of this common key in clear, or any other encrypted value derived 
from this common key. 

30 On reception of such a request for authentification ET in response to at least 

one keyboard command by the user, another remote control T2 will send an 
acquisition signal to Tl as long as T2 has verified that the old common key 
transmitted by Tl was in fact the one known to T2. Only upon reception of such an 
acquisition signal is the remote control Tl able to modify its own common key by 
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creating NK while keeping the old key OK in memory. In order to increase the 
security related to this method, it can be required that the acquisition signal be 
transmitted in a short time span following the transmission of the particular 
authentification request signal. 
5 In a second variant, at least two control points are required to generate a new 

common key, which reduces the possibility of fraudulent usage. Thus it is not possible 
to change the common key using simply a stray actuator. 

After this first step, one of the objects - a remote control in the example - is 
provided with the new key. It is then necessary to transmit the new key NK to the 

1 0 other control points . 

According to a first variant, this transmission takes place in a more or less 
collective fashion, i.e. point-to-multipoints; according to a second variant, this 
transmission takes place by a succession of point-to-point transmissions. In the first 
variant, the object which contains the new key addresses, in response to a specific 

15 keyboard command from the user, or directly after the generation of the new key, a 
message to the group of objects requesting changing of the key; the message contains 
both the old key OK and the new key NK. Any object receiving this message, 
optionally repeated within a time span of a few minutes, changes its own current 
common key to the new key NK, after having verified the identity of its current key 

20 with the old key OK. The verification of the old key prevents an object from a 
neighbouring installation changing its key by receiving the message with the new key. 
This first variant exploits the capabilities of the objects to be transmitted and received; 
it has the advantage of simplicity - because the user needs only to be provided with 
one object to cause the new key to be provided to all the objects of the installation. 

25 Another form of this first variant which is called collective consists in the 

object which is provided with the new key simply sending a command to change the 
key accompanied by the new key NK. Each object receiving the general command 
requesting changing of the key then engages a dialogue of authentification with the 
object provided with the new key, and only accepts the new key NK if this dialogue 

30 proves that the object provided with the new key contains the old common key OK. 
As in the preceding form, this prevents an object from an installation from reacting to 
a command to change the key issued by an object from another installation. 

In the second variant, the new key is transmitted from object to object, with at 
least one user operation in each transmission. The transmission of the new common 
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key is accompanied by the transmission of the old common key, or leads to a dialogue 
which proves to the object receiving the new key that the object transmitting the new 
common key also had the old one. Allowing for a user operation in each transmission 
makes the provision of the new key safe. Thus, even if the object to be expelled is still 
5 within radio range - for example because it is simply lost in the house- it is not 
provided with the new key. This improves the security because the presence of an 
object to be excluded within radio range of the other objects nonetheless allows it to 
be excluded. This prevents an object from being picked up by a passer-by who would 
use it fraudulently. Moreover, this variant accepts a mode of low consumption of the 
10 control points, which only gives these a reception functioning in a manual activation. 
In this second variant it is also possible to require the use of two objects to generate 
the new key. 

These two variants can be implemented for the group of objects; however it is 
advantageous however to use them only to transmit the new key to the bidirectional 

15 objects used as control points. The control points are easily accessible to the user, 
which makes the second variant easy to implement. By contrast it may be difficult for 
the user to access each operating unit or receiver for a manual command. These 
variants could also only be implemented for roving remote controls, i.e. for the 
control points which are not fixed: we may start from the principle that the fixed 

20 control points cannot normally disappear. 

If one or the other of these variants is implemented for the control points only 
- or for a sub-group amongst them - the new key can then be transmitted to the other 
objects as explained below. The transmission of the new key to the actuators can 
initially be realized according to the modalities given in the patent application 02 

25 01631 of Februaary 11, 2002. In this application, it is proposed to apply an initiator 
event to several objects in a synchronous fashion, such as a double cutting of the 
power supply. Then there is sending - for example by one of the objects which has 
been subjected to the initiator event - of a message containing a group identifier. An 
object which has been subjected to the initiator event and which receives this message 

30 stores the group identifier, and then considers that it is part of the group defined by 
this identifier. The moment of application of the initiator event can serve as a time 
reference in each object to secure the definition of the group. 

To transmit the new key, the initiator event can be constituted by a collective 
command specific to the remote control which is already provided with the new key; 
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the initiator event can also be constituted by a specific action on a power supply line 
common to the actuators, if necessary followed by the reception of a new key. As long 
as the actuators or the fixed control points are identified as such - for example upon 
installation or in the factory - it is sure to send the new key, if appropriate 
5 accompanied by the old key, to the actuators and/or the control points: in fact, such a 
command can be accepted only by objects identified as fixed and would not be 
accepted by a mobile control point which is lost. This solution also applies to the 
replacement of a fixed object: it would be sufficient for the fixed object to be replaced 
not to be subjected to the initiator event. In the case of a fixed control point the battery 

10 power supply can simply be removed; for an actuator or a control point connected to 
the mains, the control point can be disconnected. 

From the point of view of an object, the method described above simply 
involves receiving a new key, verifying when the command is subsequently sent - 
being transmitted or received - that the targeted object or sender is provided with the 

15 same new key and invalidating the pairing if the pairing existed previously and if the 
verification is negative. An operating program of an object thus comprises routines 
adapted to the implementation of each step of the method. 

The implementation by programming of the different steps proposed is not 
detailed: a person skilled in the art is capable of this using programming techniques 

20 known per se, using the information provided in the above description. 

The method described above has the following advantages: in the case of loss 
or stealing of an object - a remote control for example - there is no need to implement 
a full re-pairing procedure to reestablish all the pairings between valid remote controls 
and actuators: these individual pairings are simply suspended by the method of 

25 changing the common key and become valid again by a simple confirmation of a 
match with the new common key; for the user, it is only necessary to launch the 
provision of a new key, the other steps cannot be detected and do not require the 
intervention of the user. 

Even in the case where the user is required to validate the transmission of the 

30 new key on each control point, the method keeps the pairings. The number of actions 
is thus only a function of the number of control points and not on the number of 
pairings. In the example proposed above, if the remote control 16 disappears, the 
transmission of the new key can be validated on the remote controls 18 and 20, 
without having to reestablish the pairings (12, 18),(4, 20), (8, 20) and (12, 20). 
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From the point of view of security, the example of FIG. 3 allows provision of 
the common key with much lower security constraints than for the pairing. In fact it is 
not a problem if the new common key is also accidentally provided to non-paired 
command transmitters: these command transmitters are not paired and thus cannot use 
5 this common key. This is clearly seen in the flowchart of FIG. 3, because a command 
transmitted by a non-paired transmitter is refused (step 48, 52). 

Another advantage is that the common key can be globally provided to all the 
transmitters of an installation, without consideration of the pairings. 

The invention is not of course limited to the embodiments given above. The 
10 radio transmission used between a transmitter and a receiver is given as an example 
only and can be modified. The invention applies in particular when the transmitters 
and receivers use a single frequency or each transmit on a separate frequency, or by 
frequency hopping, or with different modulations. Separate transmission mediums 
could also be used in the transmitter to receiver direction or in the receiver to 
15 transmitter direction, or separate transmission mediums for separate groups of 
transmitters or senders. In fact the method applies whenever the command 
transmitters or receivers are "bidirectional objects" capable of transmitting and 
receiving. 

The terms "command receivers" and "operating units" have been used, which 
20 apply in particular to the example of operating units of rolling shutters. The receiver 
and the operating unit can be separate elements, as in the examples, or else they can 
form a single assembly - for example by integration of the command receiver into the 
operating unit. 

Obviously the messages or the identifiers can be coded or encrypted using the 
25 techniques known from the state of the art. 



